In the field of data handling, clients such as different companies, enterprises, organizations and authorities have a need for hardware and software resources in order to perform various data processing and storing operations. In this disclosure, the term “resources” is used for short to represent any hardware and software that can be used for computer executed operations such as data processing, calculations, compilations and data storing.
Traditionally, the clients themselves own and maintain all the resources they need which can be quite costly and time-consuming, though. For example, considerable knowledge is required to first find out what type of resources is needed and to acquire and install those resources. The client thus often needs to employ skilled staff and/or hire consultants to enable efficient use of resources. Furthermore, as the technique is developing and progressing rapidly particularly in the field of computers and software, purchased or hired resources tend to become out-of-date very quickly and must frequently be replaced by new resources with better performance, which is naturally costly and time-consuming. Another problem is that a client may need a great amount of resources for a very limited period to make some large operation once or just a few times a year, e.g. related to economics, statistics or stock inventory, while very little resources are used during the remainder periods. The client thus has to make investments in resources enough to cope with such peak usage.
In recent years, the concept of cloud computing has emerged to solve the above problems for clients who instead can utilize pooled resources maintained by cloud providers in large data centers with a huge range of computers and data storages. Such data centers with huge amounts of resources are commonly referred to as “the cloud” which term will be used hereafter. Effectively, all the needed capacity is available from the cloud provider and the clients do not have to make their own investments in costly resources. Resources in the cloud are dynamically allocated to clients on a temporary basis, to be released after the client has been served. New resources in the cloud can be allocated again to the client whenever needed. Examples of cloud providers of today include Microsoft, Google and Amazon. Further, some examples of software products commonly used by cloud providers are VMWare, Citrix and Openstack.
A client is thus able to contact a cloud provider to create a so-called “virtual machine” (VM) comprising resources allocated in the cloud as needed and required by the client who can then use the VM basically in the same way as if corresponding resources were owned and hosted by the client himself. In order to achieve that, a so-called “VM image”, associated with the VM, is installed and stored in the cloud which VM image is comprised of a system of files of an operating system configured to run the VM. The VM image thus provides a means to handle input data and process requests from the client when the VM is running in the cloud. To allow a complete installation of a VM, the VM image often includes a considerable chunk of data of a size typically ranging from 1 GB to 300 GB or even more depending on the requirements of the associated VM.
A VM image may be stored in various formats which may include a set of standard, or “default”, VM image formats commonly used by clients which can be preconfigured in the cloud and readily available. Alternatively, a client can create his own tailored VM image with specific requirements and upload it to the cloud for installation, and the two alternatives above will be referred to as “standard VM images” and “specific VM images”, respectively, in this disclosure.
A communication scenario for cloud computing is schematically shown in FIG. 1 in which a data center 100, forming a cloud of resources, is maintained by a cloud provider. In the cloud, a multitude of VMs 102 can be created for different clients, each VM being comprised of a set of temporarily allocated resources, and different VM images which have been installed as described above, may be used for running the VMs. Further, one VM image can be used to run several VMs or “VM instances”. The VMs 102 and associated VM images are managed by a function denoted cloud management 104 which may be implemented in a suitable network node. The cloud management 104 in this context is also commonly referred to as the “cloud orchestration layer”. In this example, a client 106 uploads his own specific VM image to the cloud management 104, shown in an action 1:1, for installation in the cloud. Alternatively, a client can just chose a standard VM image already available and installed in the cloud for running a VM.
The cloud management 104 installs and stores the uploaded VM image 102b in the cloud, in an action 1:2, to work as an operating system for running the VM 102a. The cloud management 104 also returns an image identification to the client, in an action 1:3, which will be referenced by the client 106 in a request to the cloud management 104, indicated by an action 1:4, for creating the VM. The cloud management 104 then allocates the needed resources to create the VM 102a for client 106, in a next action 1:5, the resources being controlled by the operating system files in the VM image 102b when running the VM. The image identification is also referenced whenever the client 106 wants to change the VM image 102b in some way, e.g. delete, update or modify it, as indicated by another action 1:6. For example, it may be desired to change some metadata of the image such as its name, permissions to use the VM image, login details, and so forth. The client 106 can make such a change of the VM image 102b by communicating over a suitable Application Programming Interface (API), not shown, to access the operating system of the VM image 102b. 
In the above example, all resources are assumed to be located in the same data center of a single cloud. Sometimes, the client operates from several widely separated locations, e.g. in different countries, and in that case it would be efficient to use a distributed cloud with several local data centers forming clouds located near the client and using local protocols, formats and APIs. A reason for using such a scenario might be that the general network latency and need for network bandwidth can be reduced thanks to shorter communication paths, and/or that certain information needed for the VM may be only available to the respective local data centers, e.g. cell-related information of a cellular network for wireless communication. The above-described VM and associated VM image must then be installed in each cloud which may be managed by different cloud providers. For example, one cloud may be managed by Google, another by Amazon, and so forth. It is thus possible for a client to use a distributed heterogeneous cloud comprising a plurality of local data centers with VMs and associated VM images, to overcome various limitations e.g. relating to network latency, network bandwidth, and application specific requirements.
However, it is a problem when such a distributed heterogeneous cloud is used that the client must upload his VM image multiple times in several local data centers. As mentioned above, a VM image with operating system files may be of 300 GB size or more and uploading such an amount of data to different data centers perhaps 30 times or more using several different protocols, image formats and APIs, is quite a burdensome task for any client if a distributed cloud is wanted.
Another problematic issue is that each local cloud management, using its own protocols, formats and API, will return a local VM identification to the client who may end up with a variety of different VM identifications of the same VM image in different data centers and the local VM identifications may even overlap with one another. The client is thus required to communicate with several different data centers of a distributed heterogeneous cloud, using different procedures, protocols, formats and APIs, and to handle different returned VM identifications of the same image with the risk of mixing up the different VM identifications.